home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1129 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.6 KB
  1. Date: Thu, 3 Mar 1994 19:17:38 -0500
  2. From: "Nicholas S Castellano" <entropy@terminator.rs.itd.umich.edu>
  3. To: nox@jelal.north.de
  4.         mint@atari.archive.umich.edu
  5. In-Reply-To: Juergen Lock's message of Thu, 3 Mar 94 19:15:04 CET <9403031815.AA00152@jelal.north.de>
  6. Subject: user-written interrupt handlers
  7.  
  8. >> On the other hand, it should be _possible_ for an interrupt handler to
  9. >> raise a signal; for instance, in the case of a SLIP handler, we'd like
  10. >> to receive a signal (or whatever) when a datagram has been completely
  11. >> received, not at every received character...
  12. >> 
  13. >> But I don't know if it is safe to call Pkill (via the kernel) in an
  14. >> interrupt handler.
  15. >
  16. > also such a call would have to return quickly if you want to use it
  17. >from a modem interrupt, otherwise you'd get receiver overruns again...
  18.  
  19. It may help if there were a way to do something like a Pkill() without
  20. the call to check_sigs() at the bottom.  Really all you want to do in
  21. the interrupt handler is mark the signal as pending, and let the
  22. handler be invoked during the next context switch to the process in
  23. question.  That way there is no need for the handler to run at any
  24. particular speed, as the worst that could happen is the signal may
  25. become pending again during the execution of the handler (but it
  26. should be blocked at that point anyway).  I don't think signals are
  27. currently checked during a context switch, so that may need to change
  28. for this to work.
  29.  
  30. Cheers,
  31. entropy
  32.  
  33. --
  34. entropy -- it's not just a good idea, it's the second law.
  35. Personal mail:      entropy@gnu.ai.mit.edu
  36. MiNT library mail:  entropy@terminator.rs.itd.umich.edu
  37. "what do you have against octal?" -jrb
  38.  
  39.